What

Fixes WP_HTML_Decoder::attribute_starts_with() so it correctly answers whether a decoded attribute value starts with the requested decoded prefix.

Issue

The existing loop returned true whenever the raw haystack ended, even if the search string had not been fully matched. It also required a decoded character reference replacement to match the full replacement, which rejected valid prefix checks that end inside a multi-code-point replacement.

Reproduction

On trunk, these calls produce the wrong answers:

var_dump( WP_HTML_Decoder::attribute_starts_with( "", "http" ) );
var_dump( WP_HTML_Decoder::attribute_starts_with( "jav", "javascript:" ) );
var_dump( WP_HTML_Decoder::attribute_starts_with( "&nvlt;script", "<" ) );

Expected:

false
false
true

Before this change the first two calls incorrectly returned true, because the raw attribute ended before the search string did. The third call incorrectly returned false, because <⃒ decodes to a multi-code-point replacement beginning with <, and the search prefix may legitimately end after only that first decoded code point.

Fix

When a character reference is decoded, compare only the remaining number of bytes in the search string. Then return true only if the full search string has been consumed.

Validation

vendor/bin/phpunit --filter test_attribute_starts_with_heeds_case_sensitivity tests/phpunit/tests/html-api/wpHtmlDecoder.php

Result: OK, 13 tests, 13 assertions.

Trac ticket: TBD

Use of AI Tools

AI assistance: Yes
Tool(s): Codex
Model(s): GPT-5
Used for: splitting the fuzzer-discovered fix into a focused PR, drafting reproduction notes, and running validation. Final implementation was reviewed against the branch diff.

This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.